home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 878 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.0 KB
  1. From: clamage@Eng.Sun.COM (Steve Clamage)
  2. Message-ID: <4jbto7$78i@engnews1.Eng.Sun.COM>
  3. X-Original-Date: 27 Mar 1996 17:26:31 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 27 Mar 96 20:12:00 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Quick questions (but no longer so quick)
  9. Organization: Sun Microsystems Inc.
  10. References: <4jajk2$17aq@mule1.mindspring.com>
  11. Reply-To: clamage@Eng.Sun.COM
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMVmhROEDnX0m9pzZAQGnswF/Q6yOaso4UkuAY7F+p6Tc0ClSOwPWEO3A
  14.     OunLFEsksnBuspExsLBKof15lcFRCEXO
  15.     =VO3e
  16.  
  17. In article 17aq@mule1.mindspring.com, abell@mindspring.com (Andrew Bell)
  18. writes:
  19. >clamage@Eng.sun.com (Steve Clamage) wrote [but much edited by me]:
  20. >
  21. >>I assume you mean a class like
  22. >>    class Short { short val; };
  23. >>with non-virtual member functions added. You can't assume the size and
  24. >>alignment of the class will be the same as its only data member, and no,
  25. >>the standard provides no special support for this special case.
  26. >
  27. >Seems like if you only have one data member and no virtual functions,
  28. >there's no reason to arbitrarily restrict it to a greater alignment
  29. >level, save maybe to make compiler programmer's lives (and maybe
  30. >debugger programmer's lives) trivially easier. 
  31.  
  32. That isn't the reason. C++ implementations don't exist in a vacuum. They
  33. have to coexist with platform ABIs (Application Binary Interface, the
  34. bit-level description of data and function calls). It is common for an ABI
  35. to specify rules for structured types that are different from the rules
  36. for simple types, no matter what the contents of the structure. That is,
  37. all structured types are treated by one set of rules.
  38.  
  39. If a platform ABI required that all structs be at least 4-byte aligned and
  40. padded to 4-byte boundaries, but C++ required that struct alignment and
  41. padding be no stricter than that of the strictest member, you place the C++
  42. implementor in an impossible position. Either the generated code is
  43. incompatible with system and 3rd-party libraries, or the compiler violates
  44. the C++ standard.
  45.  
  46. Nothing prevents an implementation from implementing class Short above in
  47. the same way as type short if the ABI allows it, but the point is that you
  48. can't depend on type Short being either the same as or different from
  49. type short.
  50.  
  51. >>The typeids of two types compare equal if and only if they are
  52. >>the same type. Base and derived classes are not ever the same type.
  53. >
  54. >Fair enough, although in this case RTTI forces the creation of an
  55. >additional vtable that wouldn't normally be necessary.  Since the
  56. >general criterion for RTTI support in a class in the first place is
  57. >the existence of any virtual functions (and thus a vtable), it doesn't
  58. >seem like it would be too unreasonable to make classes with identical
  59. >vtables evaluate to the same thing.  Adding an operator to a class
  60. >(externally) doesn't change its identity; should a non-virtual member
  61. >function do so?
  62.  
  63. That's a philosophical question about what is a type. C++ follows the
  64. common convention that different types are different types. The One-
  65. Definition Rule says that there is only one definition of a type in
  66. a program. In addition, the type must be defined in a single declaration,
  67. not spread out. Some consequences of this consistent set of rules are that
  68. a derived type is always a different type from the base, and namespace-scope
  69. functions are not part of any class's type.
  70.  
  71. Certainly different rules are possible, and other languages have other
  72. rules. The C++ rules are easy to understand and the consequences are
  73. easy to predict. Not so if type equivalence depends on subtle distinctions.
  74.  
  75. ---
  76. Steve Clamage, stephen.clamage@eng.sun.com
  77. ---
  78. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  79. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  80. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  81. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  82. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  83.